The present invention relates to forward chaining in the field of computers. More specifically, the present invention relates to a method for enforcing context model based policies with forward chaining and a policy engine, especially in a Service-Oriented Architecture (SOA) system.
Service-Oriented Architecture (SOA) is a software system architecture which is realized by connecting independent functional entities capable of completing specific tasks to meet requirements of business integration in an Internet or networked environment. In other words, an SOA system incorporates a component model which links different function units (called services) of an application through interfaces and contracts properly defined among these services, wherein the definition of the interfaces is independent of the hardware platform, operating system, and programming language for realizing services. The SOA uses the service-oriented modeling technique and WEB service technique to accomplish loose coupling between systems, and, thus, realize integration and cooperation between the systems.
The SOA policy is an important component of the SOA system and is used for declarative description and execution of the SOA system behavior. In the SOA system, the usage of the SOA policy spans different phases across the SOA lifecycle, including design time validation, deployment time policy publication and package and runtime service selection, change management, and impact analysis.
Generally, the SOA policy can be classified into the following types in different layers: (1) Business policy for business decision making and industry guideline compliance, etc.; (2) Application policy for service selection during service invocation, etc.; and (3) Governance policy for enforcing rules for standards compliance, and defining system behaviors for governance process, etc.
A main feature of SOA is that all the data and contexts are described in XML language, and a document containing such data and contexts is called an SOA metadata document. Generally, the SOA metadata document can include the following: a service metadata document for describing contents relating to a service, a runtime information document for describing contents relating to the runtime information, and a document for describing other business contents. For example, the service metadata document may use Web Service Description Language (WSDL), XML Schema Definition (XSD), Web Service Policy (WS-Policy), Service Component Definition Language (SCDL), Business Process Execution Language (BPEL), Service Component Architecture (SCA) policy, etc. The runtime information document may use Simple Object Access Protocol (SOAP), Representational State Transfer (REST), etc. The document for describing other business contents may use Service Data Object (SDO), Web Ontology Language (OWL), etc.
The SOA policy can be generated by conventional business policy/rule definition tools and transformation mechanism, be generated based on ontology, be generated using Service Modeling Language (SML) Rule and Schematron, or be generated based on a context model constructed by a set of XML documents.
When the policies are enforced using the corresponding policy engines, some policy/rule engines can support forward chaining for reasoning a set of policies/rules applied to specific policy subjects. The so-called forward chaining is a forward chaining for the set of rules in a rule system. Particularly, if the execution of rule 1 changes a state of a target system on which the current set of rules operates and causes rule 2 to be matched and executed, the reasoning from rule 1 applying to and matched with rule 2 is called forwarding. Thus, if there exists a chaining of rule 1→rule 2 . . . →rule n, the reasoning of the rule engine on the whole chain is called forward chaining. Forward chaining is a mechanism which allows the policies/rules applied to the same knowledge space to be inter-triggered; that is, the execution of one policy/rule is triggered by the execution of another policy/rule.
In a forward chaining mechanism, the policies/rules are parsed as a memory model, and variables referenced in the condition part and action part of the policy/rule are represented as memory variables. During the execution of forward chaining, deduction is performed by updating the memory variables and interchanging states across the different policies/rules. FIG. 1 is a schematic diagram showing an example of the existing forward chaining mechanism. As shown in FIG. 1, “WM” represents working memory which could be regarded as a storage unit of variables of the policies/rules. The variable may be changed by another rule's execution. In the forward chaining mechanism, the most time consuming step is matching the WM with the condition part of the policy/rule. This step discovers the effective WMs which have been changed by a rule's execution and which will trigger another rule.
There are lots of forward chaining algorithms in the prior art, and the most famous is the RETE algorithm. The main features of this algorithm are: (1) state-saving, i.e. after each change to the WM, the state (result) of the matching process is saved in α and β memories (after the next change of the WM, many of the results are usually unchanged, so the RETE algorithm avoids a lot of re-computation by keeping these results between successive WM changes); (2) sharing of nodes between productions with similar conditions, (i.e. at the output of the network, when two or more productions have a common condition, the RETE algorithm uses a single α memory for the condition rather than creating a duplicate memory for each production, and in the β part of the network, when two or more productions have the same conditions, the same nodes are used to match these conditions, thereby avoiding duplication of the matching).
However, existing policy/rule engines with forward chaining lack dedicated solutions for the target system and policy/rule using XML format. For example, the RETE algorithm assumes that both the policies/rules and the context to be validated will be parsed as a memory model to interchange states across different policy/rule's execution. However, in the target system using the XML format, Document Object Model (DOM) consumes a lot of memory, and it is, therefore, difficult to locate specified elements in a large XML document. Thus, the policies/rules and the applied model in XML format are not adapted to be periodically loaded in the memory model. In addition, the traditional way to validate the XML content does not require a memory model, and, thus, the RETE algorithm will lose its position.
The Service Modeling Language (SML) and the SML based policy engine will now be briefly introduced. SML has been defined by IBM, Microsoft, BEA, Intel, etc., for XML-based IT service management. It provides a rich set of constructs for describing models of complex IT services and systems. The SML model is a set of interrelated XML documents. The XML documents contain information about the parts of an IT service, as well as the constraints which each part must satisfy for the IT service to function properly.
The documents in a SML model include definition documents and instance documents. A definition document is described with XML Schema Definition (XSD) language and Schematron Schema language and is a subset of documents in the SML model that describes the schemas and polices/rules that govern the structure and content of the documents in the model. The SML specification defines two kinds of definition documents; (1) XML schema documents which conform to SML's profile of XML schema, and (2) policy/rule documents which conform to SML's profile of Schematron. The policy/rule documents are Boolean expressions that constrain the structure and content of the documents in the model. An instance document is in XML format and is a subset of documents in the SML model that describes the structure and content of the modeled entities.
However, the SML based engine is only for one-step validation of system configuration and report. SML utilizes Schematron as policy/rule expressions to validate its instance documents. According to Schematron specifications, the policies/rules within the standard Schematron can only report diagnosis messages in text string format when there exist violations to policy/rule restrictions. The SML specification extends the capability of validation reports to bring in structured output, but this extension only provides a standard output of elements or attributes, without further semantics. In addition, the Schematron based policies/rules applied to the SML model cannot update the SML model by itself. Therefore, those policies/rules cannot form a chain using the forward chaining mechanism.